(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY <PCT) 



(19) World Intellectual Property Organization 
International Bureau 

(43) International Publication Date 
13 March 2003 (13.03.2003) 




(10) International Publication Number 

PCT WO 03/021415 Al 



(51) International Patent Classification 7 : G06F3/00, 17/30 

(21) International Application Number: PCT/US02/27386 

(22) International Filing Date: 28 August 2002 (28.08.2002) 

(25) Filing Language: English 

(26) Publication Language: 



(30) Priority Data: 

09/942,833 



Enclish 



29 August 2001 (29.08.200L) US 



(71) Applicant: INTELLIDEN, INC. [US/US]; 90 South 
Cascade Avenue, Suite 500, Colorado Springs, CO 80903 
(US). 

(72) Inventor: COURTNEY, Mike; 8062 Cooper River Drive, 
Colorado Springs, CO 80920 (US). 

(74) Agent: COOLEY CODWARD LLP; Attn: Patent Group. 
One Freedom Square, Reston Town Center, 1 195 1 Freedom 
Drive, Reston, VA 20190-5656 (US). 



(81) Designated States (national): Alt. AG, AL, AM, AT, AU, 
AZ, BA, BB. BG, BR, BY, BZ, CA, CH, CN. CO, CR, Cv\ 
CZ, DE, DK. DM. DZ. EC, EE, ES, FI, GB, GD. GE. Gil, 
GM, IIR. HU, ID, IL. IN, IS. JP, KE. KG. KP, KR, KZ, LC, 
LK, LR, LS, LT, LU, LV, MA. MD, MG, MK, MN, MW, 
MX, MZ, NO, NZ, OM, PH, PL, PT, RO, RU, SD, SE, SG, 
SI, SK, SL, TJ, TM. TN, TR, IT, TZ, UA, UG, UZ, VN, 
YU, ZA, ZM, ZW. 

(84) Designated States (regional): ARIPO patent (GH. GM, 
KE, LS, MW, MZ, SD. SL. SZ. T/ ? UG, ZM, ZW), 
Eurasian patent (AM, AZ, BY, KC5, KZ. MD ? RU, TJ, TM), 
European patent (AT, BE, BG. CI I, CY, CV., DE, DK. EE. 
ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE, SK, 
TR), OAPI patent (BF, BJ. CI , CCi, CI, CM. GA, GN, GQ, 
GW, ML, MR. NE, SN, TD, TG>. 

Published: 

— with international search report 

— before the expiration of the time limit for amending the 
claims and to be republished in the event of receipt of 
amendments 

For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations" appearing at the begin- 
ning of each regular issue of the PCT Gazette. 



=5 <54) Title: SYSTEM AND METHOD FOR MODELING A NETWORK DEVICE'S CONFIGURATION 



155 

\ 




Network Device 




DOM Generator 






JUGfi 



< 
o 




L 122 



XML-XML 
Converter 
I2£ 



Comparator 
210 



XML-CLI 
Converter 

_220_ 



LDAP 
225 



L 215 



(57) Abstract: A system and method for modeling the configuration of a network device is described. Such a system could include, 
for example, a CLI-to-XML converter (185) connected to a schema storage device (170) or a CLUo-XM I. converter in combination 
with document object model (DOM) generator. Other embodiments could include a CLI-to-XML converter, a schema hash system, 
and a DOM izenerator. 



WO 03/021415 



PCT/US02/27J86 



SYSTEM AND METHOD FOR 
MODELING A NETWORK DEVICE'S CONFIGURATION 



BTF.T n OF THE INVENTION 

5 The present invention relates to network device configuration. In particular, but 

not by way of limitation, the present invention relates to systems and methods for 
retrieving configurations from network devices and generating corresponding command 
models. 

BACKGROUND OF THE I NVENTION 

10 Networks, and in particular, the Internet, have revolutionized communications. 

Data vital to the continued prosperity of the world economy is constantly being 
exchanged between end-users over these networks. Unfortunately, the expansion and 
maintenance of present networks is outpaced by the demand for additional bandwidth. 
Network equipment is often difficult to configure, and qualified network engineers are 
1 5 in extremely short supply. Thus, many needed network expansions and upgrades must 
be delayed until these engineers are available. While these upgrades and expansions 
are pending, end-users continue to suffer poor network performance. 

Cisco™ routers, for example, are notoriously difficult to configure-especially 
in light of the new XML-based interfaces introduced by competitors such as Juniper 
20 Networks™. Instead of a user-friendly XML-based interface, Cisco™ uses a 

cumbersome command line interface (CLI ) for its routers. Cisco's™ CLI is the result 
of many years of semi-controlled modifications to its router operating systems and has 
resulted in a tangled mess of commands and subcommands. This cumbersome 
interface is one reason that Cisco™ requires that Cisco-certified engineers work on its 
25 routers. 

Cisco™ could reduce the complexity of its routers and reduce the need for 
Cisco-certified engineers by producing a user-friendly interface. If Cisco™ attempted 
to abandon its CLI in favor of such a user-friendly interface, however, many years of 
development and expertise could be lost. Moreover, even if it could develop a user- 
30 friendly interface, there is presently no economical way to integrate it into the 

thousands of existing Cisco™ routers. Despite the difficulties in implementing a more 
user-friendly interface, to remain competitive, Cisco™ and similarly situated 
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companies need to move away from their present interfaces. Present technology, 
however, does not provide these companies with an acceptable option that allows 
continued use of their extensive interface knowledge base while simultaneously 
providing system administrators and network engineers with a user-friendly interface. 
5 Moreover, present technologies do not provide an acceptable way to provide backward 
compatibility of new user-friendly interfaces with existing network devices. 

Cisco™, of course, is not the only network device manufacturer to face this 
interface-upgrade problem. Many manufacturers would like to continue using their 
existing interface knowledge base while providing system administrators a user- 
10 friendly, consistent interface. Accordingly, a system and method are needed that will 
allow manufacturers, like Cisco™, to create user-friendly interfaces for both next- 
generation and existing devices. 
SUMMARY OF THE INVENTION 

Exemplary embodiments of the present invention that are shown in the 

15 drawings are summarized below. These and other embodiments are more fully 

described in the Detailed Description section. It is to be understood, however, that 
there is no intention to limit the invention to the forms described in this Summary of the 
Invention or in the Detailed Description. One skilled in the art can recognize that there 
are numerous modifications, equivalents and alternative constructions that fall within 

20 the spirit and scope of the invention as expressed in the claims. 

In one embodiment, for example, the present invention can provide a system 
and method for modeling the configuration of a network device. Such a system could 
include a CLI-to-XML converter connected to a schema storage device or a CLI-to- 
XML converter in combination with a document object model (DOM) generator. Other 

25 embodiments could include, for example, a CLI-to-XML converter, a schema hash 
system, and a DOM generator. 

In operation, one embodiment of the present invention can model a network 
device's configuration by retrieving a the network device's configuration, in a native 
format, from the network device— or an alternate location— and converting it into a 

30 standard-format configuration such as an XML document or a DOM. This standard- 
format configuration provides system administrators with an easy-to-use, familiar 
device configuration format for different network devices. That is, instead of being 
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forced to manipulate a difficult CLI-based configuration format, or other format system 
administrators can use the standard-format configuration to interact with the target 
network device. Moreover, one embodiment of the present invention can allow system 
administrators to use the same standard configuration format across multiple brands 
5 and models of network devices. Thus, in networks that employ multiple brands and 
models of network devices, system administrators can be presented with similar 
configuration formats for each device despite the fact that the native configuration 
formats for the different devices are significantly different. 

The process for actually converting a native-format configuration for a network 
10 device into a standard-format configuration is generally a multi-step process. For 
example, one embodiment of the present invention initially determines the target 
network device's characteristics such as manufacturer, model, operating system version, 
etc. Next, using some or all of this characteristic information, an appropriate 
configuration schema can be retrieved from a schema storage device. Briefly, the 
15 schema can include a standard representation of the command structure for a particular 
type of network device. For example, one schema could contain a representation of the 
command structure for all model 7500 Cisco™ routers using OS version 12.1, and 
another schema could contain a representation of the command structure routers using 
OS version 12.2. The schema, its creation, and its use are fully described in commonly 

20 owned and assigned U.S. patent application no _ , Attorney Docket No. 

CNTW-007/US , entitled System and Method for Generating a Configuration Schema, 
which is incorporated herein by reference. 

In certain embodiments, this schema can be directly used to generate an XML 
document that represents the configuration of the particular network device. In the 
25 presently preferred embodiment, however, an intermediate representation, e.g., a hash 
representation, of the schema is generated and the intermediate representation is used to 
more quickly generate the corresponding XML document. By using the intermediate 
representation, the number of instruction cycles needed to generate the XML document 
is reduced significantly when compared to generating the XML document directly. 
30 To actually assemble an XML document, one embodiment of the present 

invention generates an XML representation of each native-format command in the 
network device's configuration by associating each command with the schema, or its 
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hash representation. The XML document itself can be used to represent the standard- 
format configuration, or alternatively, the XML document can be converted into a 
DOM, and the DOM can represent the standard-format configuration. Notably, the 
integrity of the generated DOM can be verified via the schema that was used to 
5 generate the XML document, thereby providing a "closed-loop" capability. 

As previously stated, the above-described embodiments and implementations 
are for illustration purposes only. Numerous other embodiments, implementations, 
and details of the invention are easily recognized by those of skill in the art from the 
following descriptions and claims. 
10 BRIEF DESCRIPTION OF THE DRAWINGS 

Various objects and advantages and a more complete understanding of the 
present invention are apparent and more readily appreciated by reference to the 
following Detailed Description and to the appended claims when taken in conjunction 
with the accompanying Drawings wherein: 
15 FIGURE 1 is a block diagram of a conventional network; 

FIGURE 2 is a block diagram of a conventional router; 
FIGURE 3 is a block diagram of one embodiment of a system constructed in 
accordance with the principles of the present invention; 

FIGURE 4 is a block diagram of an alternate embodiment of a system 
20 constructed in accordance with the principles of the present invention; 

FIGURE 5 is a block diagram of one implementation of the DOM generator 
shown in FIGURE 3; 

FIGURE 6 is a flowchart of one method for operating the DOM generator 
shown in FIGURE 5; and 
25 FIGURE 7 is a flowchart of one method for generating an intermediate 

representation described with relation to FIGURE 6. 
DETAILED DESCRIPTION 

Referring now to the drawings, where like or similar elements are designated 
with identical reference numerals throughout the several views, and referring in 
30 particular to FIGURE 1, it illustrates a block diagram of a conventional network system 
100. In this network system 100, end-users 105 are connected to servers 110, which are 
connected to networking equipment such as hubs, not shown, optical components 115, 
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and routers 120. Using the networking equipment, end-users 105 that are associated 
with different servers 110 can exchange data. 

As new servers 1 10 and end-users 105 are added to the overall system 100, or as 
new software becomes available, the routers 120 and/or optical components 1 15 of the 
5 network system 100 may need reconfiguring. To reconfigure these components, a 
system administrator 125«with the proper authorization-could access the router 120 
and/or optical component 1 15 by, for example, establishing a telnet connection to the 
component and transferring configuration instructions thereto. 

Referring now to FIGURE 2, it is a block diagram of one type of conventional 
10 router. In this representation, a processor 125 is connected to a configuration interface 
130, an operating system (OS) storage module 135, a command storage module 140, a 
configuration storage module 145, and a routing module 150. The illustrated 
arrangement of these components is logical and not meant to be an actual hardware 
diagram. Thus, the components can be combined or further separated in an actual 
1 5 implementation. Moreover, the construction of each individual component is well- 
known to those of skill in the art. 

Still referring to FIGURE 2, when a system administrator 125 wishes to 
reconfigure a router 120, he accesses the router 120 through the configuration interface 
130 and retrieves the present configuration for the router 120 from the configuration 
20 storage module 145. If necessary, the system administrator 125 can review available 
configuration commands and associated bounds by accessing and reviewing the 
commands stored in the command storage module 140. In essence, the command 
storage module 140 provides the knowledge base for a "help" screen. The commands 
stored in the command storage module 140 are often unique to the particular OS 
25 version stored in the OS module 135. 

After the system administrator 125 has assembled the new configuration 
instructions, these instructions are pushed through the configuration interface 130 and 
stored in the configuration storage module 145. As previously described, for Cisco™ 
routers, interaction is generally through a GLI. In other words, the command storage 
30 module 140 is queried through the CLI; available commands are returned through the 
CLI; and new configuration commands are provided to the router 120 through the CLI. 
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Unfortunately, the CLI is difficult to manage and requires highly skilled engineers for 
even simple tasks. 

For other routers, the configuration interface 130 could be XML based. 
Although the XML-based interface is easier to navigate than a CLI, each network 
device manufacturer that uses an XML-based interface generally structures its interface 
in a proprietary fashion. Thus, network engineers are still forced to learn many 
different interfaces and command structures even for XML-based network devices. 

Referring now to FIGURE 3, it is a block diagram of one embodiment of a 
system constructed in accordance with the principles of the present invention. In this 
embodiment, a DOM generator 160, which is more fully described with relation to 
FIGURE 5, is connected to a network device 165, a schema storage device 170, a 
system administrator 175, a DOM storage device 180, and various DOM applications 
185, which will be discussed in more detail below. 

In one method of operation, the system administrator 175 initially notifies the 
DOM generator 160 to model the configuration for the network device 165. In other 
words, the DOM generator 160 is instructed to convert the active command format for 
the network device 165 into an XML and/or DOM format. In response, the DOM 
generator 160 either polls the network device 165 to discover the device's 
characteristics, e.g., manufacturer, model, operating system version, etc., or retrieves 
the information from a database (not shown). Next, the DOM generator 160 identifies 
and retrieves, from the schema storage device 170, the schema corresponding to the 
device characteristics for the network device 165. The DOM generator 160 then 
retrieves the configuration from the network device 165 and, using the retrieved 
schema, converts the individual commands of the configuration into a DOM. The 
resulting DOM can then be stored in the DOM storage device 180 in association with 
an identifier for the network device 165. Note that storage devices 170 and 180 could, 
in fact, be integrated into a single device. 

One advantage of the DOM format is that it provides a standard format for most 
network device configurations. Generally, applications that use or manipulate network 
device configurations must be customized for each manufacturer, each model, and each 
OS version. This type of customization often requires many different versions of the 
same application. By converting each network device's configuration into a DOM 
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format, however, applications can be designed to utilize a single, standard configuration 
format and thereby limit the need for customization. 

Although many different types of applications can utilize a DOM, a select few 
are represented in FIGURE 3 as DOM applications. For example, one such application 
5 is a DOM-based graphical user interface (GUI) 190. In this application, the hashed 
schema and/or the resulting DOM instance are used to drive the GUI used by the 
system administrator 175. The advantage of such a GUI 190 is that the system 
administrator 175 is presented with network device configurations in a standard, 
consistent format regardless of the characteristics of the particular network device. 
10 Another application that utilizes the DOM is the XML-XML converter 1 95, also 

called the standard XML-to-native XML converter. As previously described, some 
network devices include XML-based interfaces. However, these XML-based interfaces 
are generally based on proprietary (native) configuration instructions. Thus, the system 
administrator 175 may interface with one XML-based network device in a very 
1 5 different way than another XML-based network device. To standardize the interface 
between these various XML-based network devices, the XML-XML converter converts 
' a standard XML-based instruction into a native XML-based instruction. In other 
words, the XML-XML converter allows the system administrator 175 to use the same 
XML-based command format for most network devices even though each device may 
20 require its own native XML-based command format. 

Like the XML-XML converter 195, the XML-CLI converter 200 allows the 
system administrator 175 to interface with CLI-based network devices using a standard 
XML-based command format instead of a CLI-based command format. Other DOM- 
based applications may include lightweight directory access protocol (LDAP) for 
25 storing and manipulating schema, hash representations, and device configuration 

commands. These converters convert XML-based configurations into a LDAP-based 
configuration and LDAP-based configurations into XML-based configurations. 

Yet another possible DOM application is the comparator 210, which is 
configurable to identify the differences between two DOMs. For example, if the 
30 configuration for a target network device were changed, the new configuration could be 
retrieved from the device and converted to a DOM. The comparator 210 could then 
compare the new DOM against the original DOM to thereby identify any changes, 
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additions, and/or deletions. The comparator can then record these changes in a markup 
DOM using a configuration change markup language and make the markup DOM 
available to the system administrator for configuration and validation purposes. 
In another embodiment of the comparator 210, the old DOM is compared 
5 against a draft DOM instead of a new DOM. In other words, the system administrator 
175 generates a draft configuration for a target network device 165. This draft 
configuration is converted into a DOM, and the comparator 210 compares it against the 
target network devices original DOM. The system administrator 175 can use this 
embodiment of the comparator to view the configuration changes before the draft DOM 

10 is finalized and pushed to the target network device 165. 

The DOM applications can also include an (API) application programming 
interface 215. This API provides a mechanism whereby the DOM can be transferred 
to/from other software programs, which may reside on network devices. Accordingly, 
the DOM can be programmatically modified outside of the embodiment and 

15 resubmitted. 

Referring now to FIGURE 4, it is a block diagram of an alternate embodiment 
of a system 220 constructed in accordance with the principles of the present invention. 
In this embodiment, the DOM generator 160 is connected through a network 225 to the 
network devices 165, the system administrator 175, the schema storage device 170, and 

20 the DOM applications 180. This embodiment illustrates that the components described 
herein can be distributed in a number of ways and without impacting the basic 
operation of this system as described with regard to FIGURE 3. 

Referring now to FIGURE 5, it is a block diagram of one implementation of the 
DOM generator 160 shown in FIGURE 3. In this embodiment, the DOM generator 160 

25 includes a schema hash system 230, an XML converter 235, and a DOM transformer 
250. These components can be connected to the schema storage device 170, the target 
network device 165, a DOM storage device 245 and an XML storage device 250. 

In this embodiment, the XML converter 235, using the appropriate schema, 
generates an XML document containing an XML representation of the network device's 

30 configuration. This XML document is then passed to the DOM transformer 240, which 
converts the XML document into a DOM. The output from the XML converter 235 
and/or the DOM transformer 240 can be stored and passed to relevant software 



8 



WO 03/021415 PCT/US02/27386 

applications. For example, the output from the XML converter 235 can be stored in the 
XML storage device 250 and the output from the DOM transformer 240 can be stored 
in the DOM storage device 245. 

Notably, the XML converter 235 of this embodiment can convert the native 
5 configuration of the network device 165 into an XML document using an intermediate 
representation of the schema associated with the network device 165, such as a hash 
table generated by the hash system 230, instead of the schema itself. By using an 
intermediate representation of the appropriate schema, the XML converter 235 can 
reduce the time and processing requirements needed to convert a native configuration 
10 into a corresponding XML document. The creation and use of the intermediate 
representation is described more fully with regard to FIGURE 6. 

The operation of the DOM generator 160 can be further illustrated by reference 
to the flowchart in FIGURE 6. As depicted, the DOM generator 160 determines the 
target network device's characteristics by polling the network device or accessing a 
15 database (not shown) containing such information (step 255). Next, the XML converter 
235 identifies the appropriate intermediate representation for the target network device 
165 (step 260). As previously described, this intermediate representation provides the 
necessary data to convert the native-format configuration of the target network device 
165 into a standard format such as an XML format. 
20 Possibly concurrently with the XML converter 235 identifying the 

corresponding intermediate representation, the XML converter 235 retrieves the 
configuration from the network device 165 and identifies each initial command within 
each configuration line (steps 265 and 270). For example, the XML converter 235 
could locate command distinguishing tags embedded in the configuration such as 
25 "begin command" and/or "end command." Alternatively, the XML converter 235 could 
use logical indicators within the configuration to distinguish the individual commands. 
Either way, using the identified initial command, the XML converter 235 generates a 
look-up key that is used to index the hash table, locate a hash map object that 
corresponds to the look-up key and retrieve that hash map object (steps 275 and 280). 
30 The hash map object contains schema information regarding the command or value 

such as whether optional or required data type, etc. Finally, using this hash map object, 
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the XML converter 235 can assemble the XML-based command and write it to the 
corresponding XML document (step 295). 

The above process should be repeated for each command in the network 
device's native-format configuration. With regard to FIGURE 6, this process is 
represented by determining whether any more commands need to be converted (step 
300). If so, branch 305 is followed to step 270 and a next native-format command is 
identified. The process for this command is then repeated. If, on the other hand, all 
native-format commands have been converted, branch 310 is followed and the XML 
converter 235 assembles all of the generated XML commands into an XML document 
that can be stored in the XML storage device and/or provided to the DOM transformer 
240 (step 315). 

Once the XML document has been assembled, it can be passed to the DOM 
transformer 240 where a DOM corresponding to the XML document can be generated 
(step 320). The process for converting an XML document to a DOM is well known in 
the art and, thus, not described here. Notably, the DOM transformer 240 can verify its 
transformation process against the appropriate schema stored in the schema storage 
device 170 (step 325). In other words, each configuration command in the DOM 
should have a particular format, which are defined by the configuration schema 
corresponding to the target network device 165. Thus, the DOM transformer 240 can 
compare the generated DOM against the corresponding configuration schema to verify 
that the DOM was properly constructed. 

Referring now to FIGURE 7, it is a flowchart of one method for generating an 
intermediate representation of a configuration schema. In this embodiment, a 
command is initially retrieved from the previously assembled configuration schema 
(step 328). Additionally, any related higher-level commands (called parent commands) 
in the configuration schema can be retrieved (step 330). The retrieved command and 
the retrieved parent commands can then be used to generate a unique hash key for the 
retrieved command (step 330). 

After the unique hash key is generated, a corresponding hash object can also be 
generated. This hash object can include basic information related to the generated hash 
key. To generate the hash object, information such as data type, sibling commands, and 
application specific information is retrieved and assembled into the schema object 
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(steps 335 and 340). The data type information, for example, can indicate whether the 
data associated with a particular command is a string, an integer, etc. and the sibling 
information can identify commands at the same hierarchical level as the initially 
retrieved command that have the same parent command as the initially retrieved 
5 command. Additionally, in certain embodiments, specialized application information 
can also be retrieved (step 345). This application information, for example, can define 
special processing requirements for a schema. 

Once the relevant information has been collected, the corresponding schema 
object can be assembled and the hash map assembled for the unique key and schema 
10 object (step 350 and 355). If there are any more commands in the schema that need to 
be modeled, branch 362 is followed and the next command can be retrieved (step 328). 
If all of the commands have been modeled, then branch 364 can be followed and the 
various hash objects can be stored as a completed hash table (step 365). 
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WHAT IS CLAIMED IS : 

1 . A method for modeling a configuration corresponding to a network device, 
wherein the configuration includes a plurality of configuration commands, the method 
comprising: 

5 determining a characteristic of the network device; 

retrieving at least a representation of a configuration schema, the at least a 
representation of a configuration schema corresponding to the determined characteristic 
of the network device; 

retrieving a first of the plurality of configuration commands from the network 
10 device configuration corresponding to the network device; and 

generating an XML object corresponding to the retrieved configuration 
command; 

wherein the XML object is generated according to at least a portion of the retrieved at 
least the representation of the configuration schema. 



15 



20 



2. The method of claim 1, wherein determining the characteristic of the network 
device comprises: 

determining one of a network device manufacturer, network device model, and 
network device operating system version. 



3. The method of claim 1, wherein the at least the representation of the 
configuration schema comprises a plurality of schema portions and wherein retrieving 
the at least the representation of the configuration schema comprises: 

retrieving an intermediate representation of the configuration schema, wherein 
25 the intermediate representation comprises a plurality of keys; 

wherein each of the plurality of keys is associated with a corresponding one of 
the plurality of schema portions. 

4. The method of claim 3, wherein retrieving the intermediate representation of the 
30 configuration schema comprises: 

retrieving a hash table. 



12 



WO 03/021415 PCT/US02/27386 

5. The method of claim 3, further comprising: 
generating a look-up key for the retrieved configuration command. 

6. The method of claim 5, further comprising: 
identifying a first of the plurality of keys in the intermediate representation, the 

first of the plurality of keys corresponding to the generated look-up key; and 

retrieving a first of the plurality of schema portions, the first of the plurality of 
schema portions corresponding to the first of the plurality of keys; 

wherein the XML object is generated according to the first of the plurality of 
schema portions. 

7. The method of claim 1, further comprising: 
converting the XML object to an XML document. 

15 8. The method of claim 7, further comprising: 

converting the XML document into a document object model (DOM). 

9. The method of claim 8, further comprising: 

verifying the DOM against the at least the representation of the configuration 
20 schema. 

10. A system for modeling a native-format network device configuration, the 

system comprising: 

an intermediate schema representation system (ISR); 
25 an XML converter connected to the ISR, the XML converter configured to 

convert the native-format network device configuration into an XML document; and 

a document object model (DOM) transformer connected to the XML converter, 
the DOM transformer configured to transform the XML document into a DOM. 

30 11. The system of claim 10, wherein the native-format network device 
configuration is associated with a router. 

13 
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12. The system of claim 10, wherein the native-format network device 
configuration is associated with a data storage system. 

13. The system of claim 10, wherein the native-format network device 
5 configuration is associated with an optical component. 

14. The system of claim 10, further comprising: 
a DOM storage device for storing the DOM. 

10 15. The system of claim 14, wherein the DOM storage device comprises temporary 
storage. 



16. The system of claim 14, further comprising: 

an XML-to-XML converter connected to the DOM storage device. 

15 

17. The system of claim 14, further comprising: 

an XML-to-CLI converter connected to the DOM storage device. 

18. The system of claim 14, further comprising: 

20 a graphical user interface connected to the DOM storage device. 

19. A system for modeling a network device configuration, the system comprising: 
a plurality of network devices; 

a DOM generator connected to the plurality of network devices; 
25 a configuration schema storage device connected to the DOM generator; and 

a DOM storage device connected to the DOM generator. 

20. The system of claim 19, further comprising: 
a DOM application connected to the DOM generator. 



30 



2 1 . The system of claim 19, wherein the configuration schema storage device 
comprises: 
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an intermediate schema representation storage device. 

22. The system of claim 19, further comprising: 

an XML-to-XML converter connected to the DOM generator. 

5 

23. The system of claim 19, further comprising: 

an XML-to-CLI converter connected to the DOM generator. 



24. A method for modeling a configuration corresponding to a network device, 
10 wherein the configuration includes a plurality of configuration commands, the method 
comprising: 

determining a characteristic of the network device; 

retrieving at least a representation of a configuration schema, the at least a 
representation of a configuration schema corresponding to the determined characteristic 

15 of the network device; 

retrieving a first of the plurality of configuration commands from the network 
device configuration corresponding to the network device; and 

generating a standard-format representation of the retrieved configuration 
command; 

20 wherein the standard-format representation is generated according to at least a 

portion of the retrieved at least a representation of the configuration schema. 

25. The method of claim 24, wherein the at least the representation of the 
configuration schema comprises a plurality of schema portions and wherein retrieving 

25 the at least the representation of the configuration schema comprises: 

retrieving an intermediate representation of the configuration schema, wherein 
the intermediate representation comprises a plurality of keys; 

wherein each of the plurality of keys is associated with a corresponding one of 
the plurality of schema portions. 

30 

26. The method of claim 25, further comprising: 

generating a look-up key for the retrieved configuration command. 
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27. The method of claim 26, further comprising: 

identifying a first of the plurality of keys in the intermediate representation, the 
first of the plurality of keys corresponding to the generated look-up key; and 

retrieving a first of the plurality of schema portions, the first of the plurality of 
5 schema portions corresponding to the first of the plurality of keys; 

wherein the standard-format representation is generated according to the first of 
the plurality of schema portions. 



28. The method of claim 24, wherein the standard-format representation comprises 
10 an XML object. 

29. A system for modeling a configuration corresponding to a network device, 
wherein the configuration includes a plurality of configuration commands, the system 
comprising: 

1 5 a processor; 

a storage device connected to the processor; and 
a plurality of instructions stored on the storage device, the plurality of 
instructions configured to cause the processor to: 

determine a characteristic of the network device; 
20 retrieve at least a representation of a configuration schema, the at least a 

representation of a configuration schema corresponding to the determined characteristic 
of the network device; 

retrieve a first of the plurality of configuration commands from the 
network device configuration corresponding to the network device; and 

- 5 generate a standard-format representation of the retrieved configuration 

command; 

wherein the standard-format representation is generated according to at least a 
portion of the retrieved at least the representation of the configuration schema. 



30. The system of claim 29, wherein the at least the representation of the 
configuration schema comprises a plurality of schema portions and wherein the 
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plurality of instructions cause the processor to retrieve the at least the representation of 
the configuration schema by: 

retrieving an intermediate representation of the configuration schema, wherein 
the intermediate representation comprises a plurality of keys; 

wherein each of the plurality of keys is associated with a corresponding one of 
the plurality of schema portions. 



5 



31. The system of claim 29, wherein the plurality of instructions are further 
configured to cause the processor to: 

10 generate a look-up key for the retrieved configuration command. 

32. The system of claim 3 1 , wherein the plurality of instructions are further 
configured to cause the processor to: 

identify a first of the plurality of keys in the intermediate representation, the 
1 5 first of the plurality of keys corresponding to the generated look-up key; and 

retrieve a first of the plurality of schema portions, the first of the plurality of 
schema portions corresponding to the first of the plurality of keys; 

wherein the standard- format representation is generated according to the first of 
the plurality of schema portions. 

20 . 

33. The system of claim 29, wherein the standard-format representation comprises 
an XML object. 

34. The system of claim 3 1 , wherein the plurality of instructions are further 
25 configured to cause the processor to: 

convert the XML object to an XML document. 

35. The system of claim 34, wherein the plurality of instructions are further 
configured to cause the processor to: 

30 convert the XML document into a document object model (DOM). 
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36. The system of claim 35, wherein the plurality of instructions are further 
configured to cause the processor to: 

verify the DOM against the at least the representation of the configuration 
schema. 
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